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COMMUNICATION OF CODEC INFORMATION 



The invention relates to communicating codec related information between a 
first communication device and a second communication device via a 
5 network. 

In wireless telecommunication systems information is transferred in an 
encoded form between a transmitting communication device and a receiving 
communication device. The transmitting communication device encodes 

10 original information into encoded information and sends it to the receiving 
communication device. The receiving communication device decodes the 
received encoded information in order to recreate the original information. 
The encoding and decoding is performed in codecs. Thus, the encoding is 
performed in a codec located in the transmitting communication device, and 

15 the decoding is performed in a codec located in the receiving communication 
device. However, since there are many different codecs available, the 
transmitting terminal and the receiving terminal have to agree upon the 
codec(s) to be used in a session. This agreeing procedure occurs during the 
initial session establishment and is called a codec negotiation procedure. 

20 

The codec negotiation procedure for third generation (3G) telecommunication 
systems is currently being standardised. One of the standard proposals for a 
codec negotiation procedure for third generation telecommunication systems 
is discussed in the following with the aid of Figures 1 and 2. 

25 

Figure 1 shows a third generation telecommunication system for providing 
codec negotiation. In the system there is formed a signalling chain between a 
first communication device (hereinafter referred as UE1, UE standing for 
User Equipment) and a second communication device (hereinafter referred 
30 as UE2). The signalling chain goes through a first Proxy Call State Control 
Function (hereinafter referred as P-CSCF1), a first Serving Call State Control 
Function (hereinafter referred as S-CSCF1), a second Serving Call State 
Control Function (hereinafter referred as P-CSCF2), a second Proxy Call 
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State Control Function (hereinafter referred as S-CSCF2). P-CSCF1, S- 
CSCF1, P-CSCF2 and S-CSCF2 are logical network entities that may be 
implemented so as to form separate physical network elements, or they may 
be incorporated in some of the already existing physical network elements. 

5 P-CSCF1 and S-CSCF1 , for example, may be incorporated in a first GGSN 
(Gateway General Packet Radio Service (GPRS) Support Node), and they 
may be controlled by a first network operator. P-CSCF2 and S-CSCF2 may 
be incorporated in a second GGSN, and they may be controlled by a second 
network operator. Interfaces between the different devices and functions 

10 mentioned above are defined in 3GPP (3 rd Generation Partnership Project) 
specifications. It is known to a person skilled in the art that network elements 
and/or control functions other than the ones shown in Figure 1 may reside in 
the system. 



15 The P-CSCF1 and S-CSCF1 are, among other things, responsible for 
providing services and reserving resources (for example radio resources) for 
the UE1. The P-CSCF1 controls the UE1 so that it does not exceed the 
resources that the network is able to provide for it. The S-CSCF1 controls the 
UE1 so that it does not exceed the resources to which its user has 

20 subscribed. 

The P-CSCF2 and S-CSCF2 are, among other things, responsible for 
providing services and reserving resources for the UE2. The P-CSCF2 
controls the UE2 so that it does not exceed the resources that the network is 
25 able to provide for it. The S-CSCF2 controls the UE2 so that it does not 
exceed the resources to which its user has subscribed. 



When the UE1 initiates a session with the UE2, the codec to be used for the 
session is to be determined (negotiated). If the session is going to be a 
30 multimedia session that is the session is going to be established with more 
than one media stream (for example an audio stream and a video stream) 
codecs to be used with each of the streams are to be negotiated. 
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According to the standard proposal (3G TS 23.228 version 1.7.0) the 
negotiation is performed in such a way that the UE1 (also referred to as the 
session originator) first generates, according to the SIP (Session Initiation 
Protocol) protocol, a SIP INVITE message comprising particular SIP header 
5 fields and a message body. According to the proposal, the message body is 
generated according to the SDP (Session Description Protocol) protocol and 
it is called an SDP body. 

The UE1 generates the SDP body in such a way that it contains a list (set) of 

10 codecs that the UE1 is able and willing to support for the session. The UE1 
sends the SIP INVITE message to the UE2. When the SIP INVITE message 
arrives at the UE2, the UE2 responds to the UE1 by generating and sending 
a reply message, also containing an SDP body, to the UE1. The reply 
message is referred to in the SIP protocol as the "183 message". The SDR-> 

15 body of the reply message contains a second list of codecs indicating the 
codecs that the UE2 is able and willing to support for the session. The 
second list is generated based on the content of the list of codecs in the SDP 
body of the SIP INVITE message and based on the UE2's ability and 
willingness to support these codecs. If the UE2 is able and willing to support 

20 all the same codecs as the UE1 this results in the second list of codecs being 
the same as the (original) list of codecs that the UE1 generated in the first 
place. However, if the UE2 is not able or willing to support, for the session, 
one or more of the codecs contained in the original list, the UE2 leaves such 
a codec or such codecs out from the second list. This being the case the 

25 second list is a sub-list of the original list. In either case, the second list 
contains the codecs that both the UE1 and the UE2 are able and willing to 
support for the session. 

When the 183 message, sent by the UE2, arrives at the UE1, the UE1 
30 decides which codec (or codecs if it is a multimedia session) of all of the 
supported codecs contained in the second list is (or are) to be used in the 
session. After it has decided this it sends to the UE2 a third message 
(referred to as the Final SDP) which tells to the UE2 the codec(s) that is (or 
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are) to be used in the session to be established. 

However, if the messages are sent in an end-to-end manner as described 
above a problem arises, because the decision of the codec(s) to be used is 
5 made without determining from the network the capacity that it is able to 
provide. For example, the chosen codec might be such a codec that requires 
a larger bandwidth than the network is able to provide at the time in question. 

One standard proposal tries to solve this problem by allowing the network 
10 entities P-CSCF1, S-CSCF1 , S-CSCF2 and P-CSCF2 to remove non- 
suitable codecs from the codec list in the SDP of the SIP INVITE message. In 
the following the matter is described in more detail referring now to Figure 2. 

After the UE1 has determined the codecs that it supports for the session -it 
15 sends the SIP INVITE message to the UE2. When the SIP INVITE arrives at 
the P-CSCF1, on its way to the UE2, the P-CSCF1 removes all non-suitable 
codec choices from the codec list in the SDP body. By a non-suitable codec 
choice is meant such a codec in the codec list that is, at the moment (or in 
general based on a network operator policy), not possible for the session 
20 from the network's point of view, the network being the one serving the UE1 . 
One example of a non-suitable codec choice would be a codec that uses too 
large a bandwidth compared to the bandwidth available in the network. 

The P-CSCF1 forwards the message to the S-CSCF1 which removes from 
25 the codec list all codecs that the UE1 is not authorised to request (based on 
user subscription information relating to the user of the UE1). 

The S-CSCF1 forwards the message to the S-CSCF2 which removes from 
the codec list all codecs that the UE2 is not authorised to use (based on user 
30 subscription information relating to the user of the UE2). 

Also, the S-CSCF1 and S-CSCF2 remove from the codec list all codecs that 
are not supported based on a network operator policy. 



WO 02/096145 PC17FI02/00434 



The S-CSCF2 forwards the message to the P-CSCF2 which removes all non- 
suitable codec choices from the codec list in the SDP body. Again, by a non- 
suitable codec choice is meant such a codec in the codec list that is, at the 
5 moment (or in general based on a network operator policy), not possible for 
the session from the network's point of view, the network now being the one 
serving the UE2. 

Finally, the P-CSCF2 forwards the SIP INVITE message to the UE2. The 
10 UE2 receives the SIP INVITE message containing the SDP body which now 
comprises a list of codecs which both the UE1 and all the logical network 
entities P-CSCF1, S-CSCF1, S-CSCF2 and P-CSCF2 are willing to support 
for the session. 

15 The UE2 now responds with a reply message (that is the 183 message) 
containing a second list of codecs. The second list is generated based on the 
content of the list of codecs in the SDP body received in the SIP INVITE 
message and based on the UE2's ability and willingness to support these 
codecs. If the UE2 is able and willing to support all the codecs contained in 

20 the list of codecs, received in the SIP INVITE message, the second list is the 
same as the list of codecs, received in the SIP INVITE message. If the UE2 
is not able or willing to support, for the session, all the codecs contained in 
the list of codecs, received in the SIP INVITE message, the UE2 leaves such 
a codec or such codecs out from the second list. In either cases, the second 

25 list is a list of codecs that both the UE1 and the UE2 and all the network 
entities P-CSCF1, S-CSCF1 , S-CSCF2 and P-CSCF2 are willing to support 
for the session. 

When the 183 message arrives at the UE1 it can make a choice which 
30 automatically takes into account the network capabilities, when deciding the 
codec(s) to be used initially in the session. Information on the chosen codec 
is sent to the UE2 in a Final SDP message, in a manner similar to that 
previously described. 
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The method described above only indicates whether a particular codec is 
supported or not However, there exist codecs which have multiple options. 
An AMR (Adaptive Multi Rate) codec, for example, is a codec which supports 
5 a plurality of different bit rates. In this case it is not enough in the codec 
negotiation procedure just to indicate whether the AMR codec is supported, 
but there is a need to indicate the bit rates of the AMR codec that are 
supported. 

10 According to a first aspect of the invention there is provided a method for 
communicating codec related information between a first communication 
device and a second communication device via a network the method 
comprising: 

transferring from the first communication device to the second 
15 communication device via the network information indicating, from a group of 
operational modes of a codec, the operational modes that the first 
communication device supports for a session between the first 
communication device and the second communication device, the method 
comprising: 

20 modifying the information, by the network, if the information is not acceptable 
to the network. 

The term session is to be construed broadly. The term session shall cover 
various sessions and connection services in which codecs are to be used. 

25 

Preferably, the network modifies the information if the network does not 
support at least one of the operational modes which the information indicates 
as being supported. 

30 Preferably, the information is received by a network entity in the network, and 
the network entity modifies the information if the network entity does not 
support at least one of the operational modes that the information, as 
received, indicates as being supported. 
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Preferably, the supported and unsupported operational modes are indicated 
with the aid of a mask having a plurality of mask elements each mask 
element being representative of one operational mode. 

5 

Preferably, each of the plurality of the mask elements indicates whether the 
corresponding operational mode is supported wherein: 
the mask element taking a first value indicates that the operational mode is 
supported; and 

1 0 the mask element taking a second value indicates that the operational mode 
is unsupported. 

Preferably, the mask is a binary mask and the mask elements are binary 
digits so that the first value of a mask element is a binary digit 1 and the 
1 5 second value is a binary digit 0. 

Preferably, the information is transferred in a message the message 
comprising a header portion and a message body the information being 
transferred in the message body. 

20 

Preferably, the message body is an SDP Session Description Protocol) body 
of a SIP (Session Initiation Protocol) INVITE message. 

Preferably, in the method, it is indicated, from a group of operational modes 
25 of a codec, the operational modes that the first communication device is 
willing and able to support for the session between the first communication 
device and the second communication device. 

Preferably, at least one of the communication devices is a mobile 
30 communication device. 

Preferably, the operational modes of the codec are the operational modes/bit 
rates of an AMR (Adaptive Multi Rate) codec. 
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According to a second aspect of the invention there is provided a transmitting 
communication device for communicating codec related information to a 
receiving communication device via a network, the transmitting 
5 communication device comprising: 

a transmitter for transmitting information to the receiving communication 
device via the network the information indicating, from a group of operational 
modes of a codec, the operational modes that the transmitting 
communication device supports for a session between the transmitting 
10 communication device and the receiving communication device, the 
transmitting communication device being configured to: 
transmit the information in a format which enables the network to modify the 
information if the information is not acceptable to the network. 

15 According to a third aspect of the invention there is provided a system for 
communicating codec related information between a first communication 
device and a second communication device the system comprising the first 
communication device, the second communication device and a network, the 
first communication device comprising: 

20 a transmitter for transmitting information from the first communication device 
to the second communication device via the network the information 
indicating, from a group of operational modes of a codec, the operational 
modes that the first communication device supports for a session between 
the first communication device and the second communication device, the 

25 network comprising: 

a processing unit for modifying the information if the information is not 
acceptable to the network. 

According to a fourth aspect of the invention there is provided a message for 
30 communicating codec related information between a first communication 
device and a second communication device via a network the message being 
configured: 

to be transferred from the first communication device to the second 
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communication device via the network the message having information 
indicating, from a group of operational modes of a codec, the operational 
modes that the first communication device supports for a session between 
the first communication device and the second communication device, the 
5 message being configured: 

to enable the network to modify the information if the information is not 
acceptable to the network. 

According to a fifth aspect of the invention there is provided a computer 
10 program product A computer program product for implementing a network 
entity the computer program product comprising: 

computer executable code for enabling the network entity to handle codec 
related information being transferred between a first communication device 
and a second communication device the information indicating, from a group- 
15 of operational modes of a codec, the operational modes that the first 
communication device supports for a session between the first 
communication device and the second communication device; and 
computer executable code for enabling the network entity to modify the 
information, if the information is not acceptable to the network entity. 

20 

It is to be understood that the operational modes that are supported may be 
indicated indirectly. This can be done, for example, in a system (and 
constituent parts thereof) which uses operational modes from a fixed, 
predetermined, set of operational modes. If, for example, operational modes 
25 that are not supported are indicated, then the supported operational modes 
should immediately be apparent. 

Embodiments of the invention will now be described by way of example only 
with reference to the accompanying drawings in which: 

30 

Figure 1 shows a third generation telecommunication system for 

providing codec negotiation; 
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Figure 2 shows a method for codec negotiation in the system 

presented in Figure 1 ; 



5 



Figure 3 shows a message structure suitable for codec negotiation; 

Figures 4a to 4e show the content of the message body of a message 
according to a preferred embodiment of the invention as 
the message travels through the network; 



10 Figure 5 shows the content of the message body of another 

message; 

Figure 6 shows a cellular mobile station suitable for the 

implementation of the invention; and 

15 

Figure 7 shows a GGSN suitable for the implementation of the 

invention. 

The system and message sequence shown in Figures 1 and 2 can also be 
20 used in a preferred embodiment of the invention. Accordingly, in the 
preferred embodiment of the invention, a first communication device UE1 first 
sends to a second communication device UE2 a SIP INVITE message in 
response to which the UE2 responds with a reply message (for example with 
a "183 message"). When the UE1 receives the reply message it decides on 
25 the codec(s) to be used in a session to be established. The UE1 generates, 
based on the decision, a third message (Final SDP) and sends the third 
message containing the information about the decided/chosen codec(s) to 
the UE2. 

30 In the preferred embodiment the UE1 is a wireless mobile station of a cellular 
radio network and the UE2 is another wireless mobile station of the same or 
another cellular radio network. An example of the cellular radio network is a 
wideband code division multiple access (WCDMA) network or another third 
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generation network. 

Figure 3 shows the basic SIP message structure. This is the basic structure 
of all the three messages sent in the preferred embodiment. A SIP message 
5 31 comprises SIP header fields 32 and a message body that is an SDP body 
33. 

The SIP header fields 32 contain information about the sender and the 
recipient of the message such as address information and other general 
10 information familiar to a person skilled in the art. 

The SDP body 33 contains information concerning those media streams (for 
example information on ports and codecs) to be used in a session. Each 
media stream is defined in the SDP with the aid of one media line that is an- - 
15 m-line. Each media stream may be even more specifically defined with the 
aid of one or more attribute lines that is one or more a-lines following the in- 
line. 

Let us now assume that the UE1 wants to initiate an audio (speech) session 
20 with the UE2. In this exemplary case the UE1 supports the following three 
codecs for the audio session: the GSM (Global System for Mobile 
communications) codec, the G.723 codec and the AMR codec. The m-line for 
this media (in the SDP of the SIP INVITE message) would then be like this: 

25 m=audio 251 70 RTP/AVP 3,4,97 , 

wherein audio indicates the media type that is audio stream, 25170 indicates 
the port number at which the UE1 wants to receive the media, RTP/AVP 
(Real-Time Transport Protocol/Audio Video Protocol) is the transport protocol 
30 to be used and the numbers 3, 4 and 97 indicate the codecs, defined in 
RTP/AVP, that the UE1 is willing to support for the session. The mappings 
according to RTP/AVP are such that number 3 indicates the GSM codec, 
number 4 indicates the G.723 codec and number 97 indicates the AMR 
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codec. 

Since the AMR codec has eight different modes of operation so that it can 
operate with eight different bit rates, these AMR modes/bit rates should also 
5 be indicated. According to the preferred embodiment of the invention the bit 
rates supported are indicated with the aid of an a-line in the SDP body. 

The AMR codec itself supports all eight bit rates, but the UE1 might not be 
able or willing to support all of the bit rates. For example, if UE1 is performing 
1 0 another task simultaneously with the session to be established it may be that 
the UE1 is not willing to support some of the highest bit rates at the initial 
stage of the session, although it might, in general, be able to support these 
bit rates. However, a typical situation is that the UE1 is both able and willing 
to support all the bit rates. 

15 

According to the preferred embodiment of the invention the AMR modes/bit 
rates supported are indicated in the a-line with the aid of a binary mask. The 
binary mask is a binary number having as many digits as there are different 
modes/bit rates. Each binary digit corresponds to a mode/bit rate in such a 

20 way that each binary digit 1 corresponds to a supported rate and each binary 
digit 0 corresponds to a unsupported rate. However, in order to consume less 
space in the SIP messages the binary mask is expressed as a decimal 
number in the a-line. It is to be noted, that depending on the implementation 
either the decimal number presentation or the binary number presentation of 

25 the binary mask is actually transmitted with the SIP messages. 

In this exemplary case the UE1 supports all the eight rates. Thus, the a-line 
(in the SDP of the SIP INVITE message) would look like this: 

30 a=fmtp:97 mode_set=0, 1,2,3,4,5,6,7/255 , 

wherein fmtp basically indicates the message body format, 97 indicates that 
the a-line is for the AMR codec, mode_set=0, 1,2,3,4,5,6,7 indicates the 
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modes/rates that the AMR codec (of the UE1) itself supports whereas the 
binary mask 255 indicates which of the bit rates (that is modes) are 
supported by the device UE1. The meaning of numbers 0 to 7 in the 
modejset and the use of the binary mask will be explained in greater detail in 
5 the following. 

In the mode_set -list the numbers 0 to 7 correspond the different AMR codec 
modes/rates in the following way: 



10 0 


<=> 


12.2 kbps 


1 


<=> 


10.2 kbps 


2 


<=> 


7.95 kbps 


3 


o 


7.40 kbps 


4 


<=> 


6.70 kbps 


15 5 


<=> 


5.90 kbps 


6 


<=> 


5.15 kbps 


7 


<=> 


4.75 kbps 



If a particular mode number is included in the a-line the corresponding 
20 mode/bit rate is supported by the AMR codec. Thus, since all the numbers 0 
to 7 appear in the list this is to be construed such that the AMR codec of the 
UE1 supports all eight modes/rates. 

Because the UE1 supports all eight rates the binary mask gets the value 
25 11111111 which corresponds to the decimal number 255. The 
correspondence between binary digits and AMR codec modes/bit rates is as 
follows: 

255 = 1 1 1 1 1 1 1 1 

30 I I I I I I I I 

0 1 2 3 4 5 6 7 (modes/bit rates). 

Thus, the mask indicates that all the AMR codec modes/rates 0 to 7 are 
supported by the UE1, because in the mask there is a binary digit 1 
35 corresponding to each of the modes/bit rates. 
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Now, the UE1 wirelessly sends the SIP INVITE message containing the SDP 
body comprising the above described m-line and a-line, as shown in Figure 
4a, to the UE2. On its way to the UE2 the network entities P-CSCF1, S- 
CSCF1, S-CSCF2 and P-CSCF2 remove any non-suitable codec choices 
5 from the list of codecs in the m-Iine. 

Relating to the AMR codec, each network entity modifies the mask in the a- 
line if it does not support one or more of the AMR modes/bit rates that the 
mask indicates as being supported. A network entity might not support a 
10 particular AMR codec mode, if for example, the particular AMR mode would 
use a larger bandwidth than the network is able to provide at the moment. 
Alternatively, based on a network operator policy, a particular AMR mode, in 
general, might not be supported. 

15 The P-CSCF1 receives the SIP INVITE message sent from the UE1. In this 
exemplary case the P-CSCF1 supports the GSM codec, the G.723 codec 
and the AMR codec. Relating to the AMR bit rates it supports all bit rates 
except 12.2 kbps, 7.40 kbps and 5.90 kbps. 

20 In this exemplary case the P-CSCF1 does not modify the m-line, because it 
supports all codecs that the list contains. However, it has to modify the a-line 
because it does not support some of the bit rates that the mask indicates as 
being supported. In other words, the P-CSCF1 changes in the binary mask 
those binary digits corresponding to the unsupported AMR bit rates 12.2 kbps 

25 (mode 0), 7.40 kbps (mode 3) and 5.90 kbps (mode 5) from value 1 to value 
0. The modification of the mask is illustrated in the following: 



255 


= 4 


1 


1 


4 


1 
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1 


1 
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30 107 


= 0 


1 


1 


0 


1 


0 


1 


1 
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I 
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After the modification the a-line of the SDP body of the SIP INVITE message 
is: 

a=fmtp:97 mode_set=0,1, 2,3,4,5,6,7/1 07 . 

5 

Now, the P-CSCF1 forwards the SIP INVITE message, containing the SDP 
as illustrated in Figure 4b, to the S-CSCF1. In this exemplary case the S- 
CSCF1 supports the GSM codec, the G.723 codec and the AMR codec. 
Relating to the AMR rates it supports all bit rates except 12.2 kbps and 7.95 
10 kbps. 

In this exemplary case the S-CSCF1 does not modify the m-line, because it 
supports all codecs that the list contains. However, it has to modify the a-line 
because it does not support some of the AMR modes/bit rates that the mask 
15 indicates as being supported. 

In other words, the S-CSCF1 changes in the binary mask the binary digit 
corresponding to the unsupported AMR bit rate 7.95 kbps (mode 2) from 
value 1 to value 0. Relating to the unsupported bit rate 12.2 kbps (mode 0) 
20 the S-CSCF1 does not have to do anything because the binary digit 
corresponding to that mode/bit rate already has the value 0. The modification 
of the mask is illustrated in the following: 

107 = 0 1 4 0 1 0 1 1 
25 I 

75 = 0 1 0 0 1 0 1 1 

I I I I I I I I 

0 1 2 3 4 5 6 7 (modes/bit rates). 

30 After the modification the a-line of the SDP body of the SIP INVITE message 
is: 



a-fmtp:97 tnode_set-0, 1,2,3,4,5,6,7/75 . 
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Now, the S-CSCF1 forwards the SIP INVITE message, containing the SDP 
as illustrated in Figure 4c, to the S-CSCF2. In this exemplary case the S- 
CSCF2 supports the GSM codec, the G.723 codec and the AMR codec. 

5 Relating to the AMR rates it supports all other rates except 12.2 kbps and 
7.95 kbps. Thus, the S-CSCF2 does not modify the m-line, because it 
supports all codecs that the list contains, and it does not have to modify the 
a-line either, because the binary digits corresponding to the unsupported 
AMR bit rates (modes 0 and 2) already have the value 0 (and thus they are 

1 0 not possible AMR bit rates for the session regardless of the capabilities of the 
S-CSCF2 since if a bit rate is not supported by at least one party 
transmission at that bit rate is not possible). 

Now, the S-CSCF2 forwards the SIP INVITE message to the P-CSCF2. In- 
15 this exemplary case the P-CSCF2 supports the GSM codec and the AMR 
codec but it does not support the G.723 codec. Relating to the AMR bit rates 
it supports all other rates except 12.2 kbps, 6,70 kbps and 5.90 kbps. Now, 
the P-CSCF2 has to modify both the m-line and the a-line. It has to modify 
the m-line because it does not support all codecs that the list in the SDP 
20 contains. The P-CSCF2 now simply removes from the codec list the 
unsupported codec choices. In this exemplary case it removes the number 4 
which corresponds to the G.723 codec according to the RTP/AVP profile. 
After the removal the m-line looks like this: 

25 m=audio 251 70 RTP/A VP 3,97. 

The P-CSCF2 also has to change the a-line because it does not support one 
of the bit rates that the mask indicates as being supported. The P-CSCF2 
changes in the binary mask the binary digit corresponding to the unsupported 
30 AMR bit rate 6.70 kbps (mode 4) from value 1 to value 0. Relating to the 
unsupported bit rates 12.2 kbps (mode 0) and 5.90 kbps (mode 5) the P- 
CSCF2 does not have to do anything because the binary digits 
corresponding to these modes/bit rates already have the value 0. The 
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modification of the mask is illustrated in the following: 
75 = 0 1 0 0 4- 0 1 1 

5 67 =01000011 
I I II I I I I 

0 f 2 3 4 5 6 7 (modes/bit rates). 

After the modification the a-line of the SDP body of the SIP INVITE message 
10 is: 

a=fmtp:97 mode_set=0, 1,2,3,4,5,6, 7/67 . 

Finally, the P-CSCF2 forwards the SIP INVITE message containing the SDP r ~ 
15 body comprising the above modified m-line and a-line, as illustrated in Figure 
4d, wirelessly to the UE2. 

The UE2 receives the SIP INVITE message. From the content of the SDP 
(that is from the m-line and the a-line) of the received SIP INVITE message it 

20 is directly derivable which of the codecs both the UE1 and all the network 
entities support for the (audio) session. In this case these codecs are the 
GSM codec (corresponding to RTP/AVP profile number 3) and the AMR 
codec (corresponding to RTP/AVP profile number 97). The mode_set in the 
a-line tells to the UE2 the modes that the AMR codec itself at the other end 

25 supports, that is the modes/rates 0 to 7. The mask in the a-line tells to the 
UE2 which of the AMR codec options (modes/bit rates) are supported by 
both the UE1 and the network entities. In this case, these are the modes 1 
(bit rate 10.2 kbps), 6 (5.15 kbps) and 7 (4.74 kbps). 

30 The UE2 now generates the second message which is the reply message (a 
183 message or a corresponding message). Again, this is a SIP message 
containing an SDP body. The reply message is generated based on the 
content of the received SIP INVITE message and based on the UE2's ability 
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and willingness to support codecs and AMR modes. The reply message also 
comprises an /77-line and an a-line the content of which is generated based 
on the content of the m-line and a-line of the received SIP INVITE message 
and based on the properties of the UE2. In this exemplary case the port 
5 where the UE2 wants to receive the media (that is audio) stream is the port 
number 26250. And the codecs that the UE2 supports for the session are: 
the GSM codec (number 3) and the AMR codec (number 97). Thus, the m- 
line of the SDP body of the reply message initially looks like this: 

1 0 m=audio 26250 RTP/AVP 3,97 , 

wherein 26250 indicates the port number at which the UE2 wants to receive 
the media, RTP/AVP (Real-Time Transport Protocol/Audio Video Protocol) is 
the transport protocol to be used and the numbers 3 (the GSM codec) and 97 
15 (the AMR codec) indicate the codecs, defined in RTP/AVP, that the UE2 is 
willing to support for the session. 

The AMR codec of the UE2 supports by definition all the AMR modes/bit 
rates, and, in this case, also the device UE2 itself, supports all AMR modes. 
20 This is a typical case. Thus, the content of the a-line of the reply message 
results in being the same as the a-line in the SDP of the SIP INVITE 
message as received at the UE2, that is: 

a=fmtp:97 mode__set=0, 1,2,3,4,5,6,7/67 . 

25 

The UE2 sends the reply message, containing the SDP as illustrated in 
Figure 4e, to the UE1. Although there should be no need for the network 
entities to modify the binary mask of the reply message further, it may be 
possible for the network entities to make such a modification if the situation in 
30 the network has changed. 

When the UE1 receives the reply message it decides, on the basis of the 
information contained in the reply message, the codec to be used initially in 
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the (audio) session. In this exemplary case the m-line contains two possible 
codecs: the GSM codec and the AMR codec, and the UE1 decides that the 
AMR codec is to be used initially in the session. 

5 The reply message contains also information on possible AMR bit rates. 
Therefore, it is now possible for the UE1 to decide on the initial AMR source 
bit rate to be used in the (audio) session. This can be done without any other 
interaction with the network entities. In this exemplary case the mask in the 
a-line in the reply message indicates three possible modes/bit rates: 10.2 
10 kbps (mode 1), 5.15 kbps (mode 6) and 4.75 kbps (mode 7), and the UE1 
decides that the AMR bit rate 10.2 kbps is to be used initially in the session. 

Now, the UE1 generates the third message (Final SDP or a corresponding 
message). Again, this is a SIP message containing an SDP body. The UE1- 

15 includes in the SDP body information concerning which codec is to be used 
initially in the session. If the chosen codec is the AMR codec, like it is in this 
case, the UE1 also includes in the SDP body information on which AMR bit 
rate is to be used initially. Other information relating to codecs may be 
conveyed in the third message, for example additional information about 

20 other bit rates and other codecs that may be used. Thus, if the codec and/or 
bit rate has to be changed during the established session the possible 
choices would already be known to the UE1 and the UE2. 

In the following, some other embodiments of the invention will be introduced. 

25 

In the preferred embodiment of the invention, described in the foregoing, it is 
assumed that the AMR bit rate which is actually used for transmission is the 
same for both directions that is from UE1 to UE2 and vice versa. In one 
alternative embodiment it is assumed that the communication devices UE1 
30 and UE2 may use different AMR bit rates in different directions. According to 
this embodiment the UE1 includes in the SDP of the SIP INVITE message 
two masks 51 and 52 (Figure 5). One mask (mask 51) may be modified by 
the network entities concerning the supported AMR bit rates in one direction 
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(from the UE1 to the UE2). The other mask (mask 52) may be modified by 
the network entities concerning the supported AMR bit rates in the other 
direction (from the UE2 to the UE1 ). 

5 According to another embodiment of the invention the UE1 includes in the 
SDP of the SIP INVITE message even more masks, one for each network 
entity. Each network entity may now modify its own mask, when the SIP 
INVITE message passes through the network entity, indicating supported 
AMR bit rates by binary digit 1 and unsupported AMR bit rates by binary digit 
10 0. In this way the communication devices UE1 and UE2 are able to 
determine the bit rates which the individual network entities support. 

According to yet another embodiment of the invention the binary mask in the 
SIP INVITE message is presented as a hexadecimal number instead of the- 
15 decimal number. Since hexadecimal numbers, in general, require less space 
than the corresponding decimal numbers, this leads to savings in the 
required space in the message. For example, the binary mask 01101011 is 
107 when presented as a decimal number and is 6B when presented as a 
hexadecimal number. 

20 

If it is assumed that the modes/bit rates that the AMR codec supports are 
generally known, it is possible to omit the numbers indicating the modes/bit 
rates from the mocfe_sef-list of the a-line. According to an embodiment of 
the invention the mode_set -list of the messages contains only the binary 
25 mask without the numbers of the modes/bit rates as follows: 

a=fmtp:97 mode__set=67 , 

wherein the decimal number 67 represents the modifiable binary mask. In 
30 this way it is possible to save space in the messages. 

The invention may be implemented by software. Figure 6 shows a cellular 
mobile station 60 suitable for the implementing the invention. The mobile 
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station 60 shown operates as the UE1. A corresponding mobile station may 
operate as the UE2. The mobile station 60 comprises a processing unit CPU, 
a radio frequency part RF and a user interface Ul. The radio frequency part 
RF and the user interface Ul are coupled to the processing unit CPU. The 
5 user interface Ul comprises a display and a keyboard (not shown) to enable 
a user to use the mobile station 60. In addition, the user interface Ul 
comprises a microphone and a speaker for receiving and producing audio 
signals. The processing unit CPU comprises a microprocessor (not shown), 
memory MEM and software SW. The software SW is stored in the memory 

10 MEM. The microprocessor controls, on the basis of the software SW, the 
operation of the mobile station 60, such as the use of the radio frequency 
part RF and the presenting of information in the user interface Ul and the 
reading of inputs received from the user interface Ul. The software SW 
comprises a WCDMA protocol stack on the basis of which a transmitter (not 

15 shown) of the radio frequency part RF transmits and a receiver (not shown) 
of the radio frequency part RF receives messages and other information with 
the aid of its antenna ANT. The codecs the support of which is negotiated 
reside in the mobile station 60. They may be implemented in the software 
SW. Another alternative is hardware implementation of the codecs (not 

20 shown). 

Figure 7 shows a GGSN suitable for implementing the invention. The GGSN 
shown serves the UE1 and a corresponding one serves the UE2. The 
GGSNs may be controlled by different network operators. The GGSN 

25 comprises a cellular network interface 71, a control unit 72 and a GGSN 
interface 73. The cellular network interface 71 and the GGSN interface 73 
are coupled to the control unit 72. The GGSN sends and receives information 
to and from the UE1 via the cellular network interface 71. Typically, there are 
several other network elements between the GGSN and the UE1. These 

30 network elements such as a base station, a base station controller and a 
SGSN (Serving GPRS Support Node) are well known by a person skilled in 
the art. The GGSN sends and receives information to and from the GGSN 
serving the UE2 via the GGSN interface 73. The latter GGSN then has a 
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corresponding cellular network interface for communicating information with 
the UE2. 

The network entities P-CSCF1 , S-CSCF1, S-CSCF2 and P-CSCF2 are 
5 logical network entities implemented by software. The network entities may 
be implemented so as to form separate physical network elements, or they 
may be incorporated in some of the already existing physical network 
elements. In this embodiment, the network entities P-CSCF1 and S-CSCF1 
are incorporated in a first GGSN and coupled with the control unit of that 
10 GGSN, and the network entities S-CSCF2 and P-CSCF2 are incorporated in 
a second GGSN and coupled with the control unit of that GGSN. 
Alternatively, the logical network entities can be located in another computer, 
but are linked with the GGSN. 

15 The control unit 72 comprises a processor or another processing unit, 
memory and software comprising a program code. The software is stored in 
the memory. The processor controls, on the basis of the software, the 
operation of the GGSN, such as the use of the cellular network interface 71 
and the GGSN interface 73. The processor of the first GGSN implements the 

20 functionality of the logical network entities P-CSCF1 and S-CSCF1 , and the 
processor of the second GGSN implements the functionality of the logical 
network entities S-CSCF2 and P-CSCF2. 

As to the method according to the invention, the microprocessor of the 
25 mobile station UE1 (Fig. 6) generates the SIP INVITE message containing 
the binary mask, by using the software SW. It forwards the SIP INVITE 
message to the radio frequency part RF which transmits the SIP INVITE 
message wirelessly to the base station of a cellular network from which the 
message is conveyed to the first GGSN (serving the UE1). The first GGSN 
30 receives the SIP INVITE message via the cellular network interface 71. The 
processor of the control unit 72 implements the modification of the m-line 
(removal of unsupported codecs) and the modification of the a-line 
(modification of the binary mask) of the SDP body according to the logical 
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network entity P-CSCF1. Thereafter the processor of the control unit 72 
implements the modification of the m-line (removal of unsupported codecs) 
and the modification of the a-line (modification of the binary mask) of the 
SDP body according to the logical network entity S-CSCF1. Here it is to be 
5 understood that although the preferred embodiment of the invention talks 
about forwarding the SIP INVITE message from the P-CSCF1 to the S- 
CSCF1 the forwarding of the message may occur, instead of a physical 
forwarding, by another type of forwarding where the message content just is 
transferred from one software process to another in one and the same 
10 device/computer. 

The control unit 72 uses the GGSN interface 73 in forwarding the SIP INVITE 
message to the second GGSN (the one serving the UE2). The second GGSN 
receives the SIP INVITE message via the GGSN interface 73. The processor 

15 of the control unit 72 implements the modification of the m-line (removal of 
unsupported codecs) and the modification of the a-line (modification of the 
binary mask) of the SDP body according to the logical network entity S- 
CSCF2. Thereafter the processor of the control unit 72 implements the 
modification of the m-line (removal of unsupported codecs) and the 

20 modification of the a-line (modification of the binary mask) of the SDP body 
according to the logical network entity P-CSCF2. Thereafter the second 
GGSN forwards the SIP INVITE message to the UE2 via the cellular network 
interface 71 . 

25 The radio frequency part RF of the UE2 receives the SIP INVITE message 
via its antenna ANT (Fig. 6) and forwards the SIP INVITE message to the 
processing unit CPU. The microprocessor of the processing unit CPU 
handles the SIP INVITE message and generates the reply message. It sends 
the reply message via the two GGSNs to the UE1. The microprocessor of the 

30 UE1 decides the codec(s) and bit rate(s) to be used initially in the session. It 
generates the third message and transmits it to the UE2 via the two GGSNs. 

According to the invention, it is possible to provide for the communication 
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devices UE1 and UE2 information about network capabilities. It is possible to 
define which of the suggested codecs are supported and which are not 
supported by the network. If a particular/single codec has multiple 
choices/options, it is also possible to provide information about whether these 
5 choices/options are supported. It is, for example, possible to tell to the 
communication devices UE1 and UE2 which AMR modes/source bit rates are 
supported by the network. When using the binary mask indicating the 
supported and unsupported modes/bit rates it is possible to consume less 
space in the messages relating to codec negotiation. 

10 

In addition to the codec negotiation procedure presented in the preceding 
description the basic message structure and the use of the mask is also 
applicable in other codec negotiation procedures where the message 
sequence may deviate from the one presented. It is clear to a person skilled * 

15 in the art that the messages also contain other information, than the m- and 
a-lines, this other information being apparent to a skilled person but not 
shown in the Figures. If it is evident that the UE1 supports all the same AMR 
modes/bit rates as the AMR codec itself, the UE1 does not necessarily have 
to insert the mask to the SIP INVITE message, but the mask may be inserted 

20 by the first network entity that does not support at least one of the modes/bit 
rates, for example the P-CSCF1. It is also possible to use some other 
message body than the SDP body in the messages. In this case, lines other 
than the m-lines and a-lines may be used, although the principle of the binary 
mask is still applicable. The invention is not restricted to the particular names 

25 of the messages (SIP INVITE, 183 message and FINAL SDP). 

Particular implementations and embodiments of the invention have been 
described. It is clear to a person skilled in the art that the invention is not 
restricted to details of the embodiments presented above, but that it can be 
30 implemented in other embodiments using equivalent means without deviating 
from the characteristics of the invention. The scope of the invention is only 
restricted by the attached patent claims. 
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Claims 



1 . A method for communicating codec related information between a first 
communication device (UE1) and a second communication device 
5 (UE2) via a network the method comprising: 

transferring from the first communication device (UE1) to the 
second communication device (UE2) via the network information 
indicating, from a group of operational modes of a codec, the 
operational modes that the first communication device supports for a 
10 session between the first communication device and the second 

communication device, characterised by 

modifying the information, by the network, if the information is 
not acceptable to the network. 

15 2. A method according to claim 1, wherein the network modifies the 
information if the network does not support at least one of the 
operational modes which the information indicates as being supported. 

3. A method according to claim 1 or claim 2, wherein the information is 
20 received by a network entity in the network, and the network entity 

modifies the information if the network entity does not support at least 
one of the operational modes that the information, as received, 
indicates as being supported. 

25 4. A method according to any of the preceding claims, wherein the 
supported and unsupported operational modes are indicated with, the 
aid of a mask having a plurality of mask elements each mask element 
being representative of one operational mode. 

30 5. A method according to claim 4, wherein each of the plurality of the 
mask elements indicates whether the corresponding operational mode 
is supported wherein: 

the mask element taking a first value indicates that the 
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operational mode is supported; and 

the mask element taking a second value indicates that the 
operational mode is unsupported. 

5 6. A method according to claim 5, wherein the mask is a binary mask and 
the mask elements are binary digits so that the first value of a mask 
element is a binary digit 1 and the second value is a binary digit 0. 

7. A method according to any of the preceding claims, wherein the 
10 information is transferred in a message (31) transmitted from the first 

communication device to the second communication device via the 
network. 

8. A method according to claim 7, wherein the message (31) comprises-a 
15 header portion (32) and a message body (33) and the information is 

transferred in the message body (33). 

9. A method according to claim 8, wherein the message body is an SDP 
Session Description Protocol) body of a SIP (Session Initiation Protocol) 

20 INVITE message. 

10. A method according to any of the preceding claims, wherein the method 
comprises: 

indicating, from a group of operational modes of a codec, the 
25 operational modes that the first communication device (UE1) is willing 

and able to support for the session between the first communication 
device (UE1) and the second communication device (UE2). 

11. A method according to any of the preceding claims, wherein at least 
30 one of the communication devices (UE1, UE2) is a mobile 

communication device. 



12. A method according to any of the preceding claims, wherein the 
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operational modes of the codec are the operational modes/bit rates of 
an AMR (Adaptive Multi Rate) codec. 



13. A transmitting communication device (UE1) for communicating codec 
5 related information to a receiving communication device (UE2) via a 

network, the transmitting communication device comprising: 

a transmitter (RF) for transmitting information to the receiving 
communication device (UE2) via the network the information indicating, 
from a group of operational modes of a codec, the operational modes 
10 that the transmitting communication device supports for a session 

between the transmitting communication device and the receiving 
communication device, characterised in that the transmitting 
communication device (UE1) is configured to: 

transmit the information in a format which enables the network 
15 to modify the information if the information is not acceptable to the 

network. 



14. A system for communicating codec related information between a first 
communication device (UE1) and a second communication device 

20 (UE2) the system comprising the first communication device, the 

second communication device and a network, the first communication 
device (UE1) comprising: 

a transmitter (RF) for transmitting information from the first 
communication device to the second communication device (UE2) via 

25 the network the information indicating, from a group of operational 

modes of a codec, the operational modes that the first communication 
device (UE1) supports for a session between the first communication 
device and the second communication device, characterised in that 
the network comprises: 

30 a processing unit (72) for modifying the information if the 

information is not acceptable to the network. 



15. A message (31) for communicating codec related information between 
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a first communication device (UE1) and a second communication 
device (UE2) via a network the message being configured: 

to be transferred from the first communication device (UE1) to 
the second communication device via the network the message (31) 
5 having information indicating, from a group of operational modes of a 

codec, the operational modes that the first communication device 
supports for a session between the first communication device and the 
second communication device, characterised in that the message (31) 
is configured: 

10 to enable the network to modify the information if the 

information is not acceptable to the network. 

16. A computer program product for implementing a network entity (P- 
CSCF1, P-CSCF2, S-CSCF1 , S-CSCF2) the computer program product 
15 comprising: 

computer executable code for enabling the network entity to 
handle codec related information being transferred between a first 
communication device (UE1) and a second communication device 
(UE2) the information indicating, from a group of operational modes of a 
20 codec, the operational modes that the first communication device 

supports for a session between the first communication device and the 
second communication device; and 

computer executable code for enabling the network entity (P- 
CSCF1, P-CSCF2, S-CSCF1, S-CSCF2) to modify the information, if 
25 the information is not acceptable to the network entity. 
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